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(57) Abstract: The present invention relates to the requirement of differentiated service to 
real time packets and other type of packets, in an IP network. More particularly it relates to 
the problem with unacceptable latency in the network resulting in real-time packet being use- 
less to the receiver. A problem for a node is to know whether a received datagram comprises 
real-time data or not An aggregated flow within an IP network passes through a Flow Classi- 
fier before entering a node. The Flow Classifier distinguishes the aggregated flow into set of 
flows, each corresponding to an uni-directional packet stream from a single session. The Flow 
Classifier executes at least one of the following checkings: checking payload size, checking 
for static behaviour in header fields that are predictably constant if the flow is a real-time flow 
or checking for incremental behaviour of header fields, which predictably increment if the flow 
is a real-time flow. Based on these checkings, the Flow Classifier decides whether the flow is 
a real-time flow or non-real-time flow. 
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IP FLOW CLASSIFIER FOR DISTINGUISHING REAL-TIME FLOWS FROM 
N ON— REAL-TIME FLOWS 



5 FIELD OF INVENTION 

The present invention relates to the field of IP (Internet Protocol) networks and 
more specifically to an IP network, a Flow Classifier and a method for classifying 
IP flows in an IP network. 



l o DESCRIPTION OF RELATED ART 

Data networks for transferring electronic information are becoming increasingly 
widespread for the communication of many different types of data including text, 
graphics, voice and video data used with a computer. Such networks enable the 
interconnection of large numbers of computer workstations, telephone and 
15 television systems, video teleconferencing systems and other facilities over 
common data links or carriers. 

Protocols between communicating computer systems are often implemented at 
multiple layers of a structural model TCP/IP (Transport Control 
Protocol/Internet Protocol) and UDP/IP (User Datagram Protocol/Internet 

20 Protocol) are used to communicate across any set of interconnected networks. The 
TCP/IP and the UDP/IP software are both organised into four conceptual layers 
that are built on a fifth layer, the hardware. The highest layer is the application 
layer, followed by the transport layer, the network layer, the data link layer and the 
physical layer, which is the hardware layer. For example the physical layer uses 

25 various transport medium, and the data link layer insures that the individual data 
packets are not corrupted during transmission between two directly connected 
systems. In TCP/IP the network and transport layers ensure that data packets 
arrive at the correct systems within a network and in a correct order. UDP/IP 
does not correct corrupted packets and does not ensure that the data packets 

30 arrive in a correct order. IP is a network protocol and TCP and UDP are transport 
protocols. Higher layers also talk to one another using various preselected 
protocols, for example RTP (Real time Transfer Protocol) which is a protocol for 
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the transpon of real-time data. Real-time data is a form of data where the 
correctness of the received packets depends not only on the logical result of the 
received data but also on the time at which the data arrives, such as audio and 
video. RTP is typically used over UDP. When transferring real-time data, using 
RTP and UDP protocols over an IP network the real-time data is broken up into 
frames. To keep track of details, such as frame sequence and timing, RTP attaches 
a header to each frame and hands over the resulting RTP frame (RTP header + 
frame) to UDP. UDP then adds its own header to the RTP frame = UDP 
datagram and hands it over to IP. IP then adds its own header to the UDP 
datagram = IP datagram. The resulting packet of data appears to be real-time data 
+ RTP header + UDP header + IP header. 

The specification documents of the Internet protocol suite, as defined by the 
IETF (Internet Engineering Task Force) and its steering group (the IESG), are 
published as RFCs (Requests for Comments). 



15 



In conventional IP networks, protocol layers operate in a rather isolated mode. 
For example, the transport layer offers the same service to all applications. Vice 
versa, applications operate independendy of the characteristics, e.g. bandwidth and 
packet loss rate, of the underlying transport network. 

20 A problem is that a too long time delay in situations of temporary overload in a 
node makes real-time data, such as audio or video useless but does not cause 
corresponding damages to other types of data. This problem would be alleviated if 
real-rime data were prioritised over non-real-time data. In this case and other cases 
where service differentiation is crucial, it is required that the server entity can 

25 distinguish between packets with different service demands. Often, one base of 
the differentiation is application category and/or different protocol format used by 
the flow. This assumes that the node in order to distinguish between packets with 
different service demands must know the type of application and/ or protocol. For 
example the use of RTP protocol points out that the flow is a real-time flow and 

30 shall in case of temporary overload be prioritised over non-real-time flow. 
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Other examples of where service differentiation is required based on whether real- 
time data or other types of data is transferred are: 

-when an outgoing link of a node is a radio link, where the allocation of radio 
recourses depends on whether the transmitted data is real-time data or non-real- 
time data, 

-requesting the link layer to recover from errors, which is not required for real- 
time data but for other types of data, and 
-access to a server or to a network. 

When protocol units are encapsulated in other lower-layer protocol units, a 
convenient way to identify the type of the encapsulated protocol is to use an 
explicit field in the header of the encapsulating lower-layer (e.g. IP) protocol. This 
is implemented in IP version 4 and IP version 6. This explicit field is the so-called 
TOS (Type Of Service) field and the network nodes that implement the 
differentiated services enhancements to IP use a codepoint in the IP header to 
select a PHB (Per-Hop Behaviour) as the specific forwarding treatment for that 
packet. This is described in the RFC 2598. 

Thus, by reading this field, any unit that processes the packet flow can easily learn 
the type of the encapsulated protocol. Unfortunately, this explicit information is 
not commonly used. 

The UDP header and TCP header do not carry any explicit information that can 
tell a receiving node that its payload contains real-time data. 

U.S. patent no. 5 903 735 describes a method and apparatus of transmitting time 
critical messages over a network path having a plurality of nodes. The data is 
classified as minimal bandwidth data in the first node and prioritised over other 
data without minimal bandwidth requirements when transmitted. The higher 
priority is maintained by the plurality of nodes of the network path. 
The problem is solved by bandwidth reservation through the path. This is, of 
course, a waist of bandwidth during those periods when less than the full 
bandwidth is required. 
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Therefore, what is further needed is a mechanism for classifying a flow as being a 
real-time flow or not, without explicit protocol format identifiers, without explicit 
flow description messages and without unnecessary waist of bandwidth. 

SUMMARY OF THE INVENTION 

The present invention relates to the requirement of differentiated service to real 
time packets and other type of packets, in an IP network. More particularly it 
relates to the problem with unacceptable latency in the network resulting in real- 
time packet being useless to the receiver. 

A problem for a node is to know whether a received datagram comprises real-time 
data or not. 



Accordingly, it is an object of the present invention to unravel the above- 
15 mentioned problems. 

The aforesaid problems are solved by means of an IP network wherein a series of 
checkings in the headers of a flow classifies the flow as being a real-time flow or 
non-real-time flow. 

20 

The following scenario of classifying a flow describes the inventive concept of the 
present invention. 

An aggregated flow within an IP network passes through a Flow Classifier before 
25 entering a node. The Flow Classifier distinguishes the aggregated flow into set of 
flows, each corresponding to an uni-directdonal packet stream from a single 
session. The Flow Classifier executes at least one of the following checkings on 
each flow: 

- checking payload size, 

30 - checking for static behaviour in header fields that are predictably constant if 
the flow is a real-time flow or 
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- checking for incremental behaviour of header fields, which predictably 

increment if the flow is a real-time flow. 
Based on these checkings, the Flow Classifier decides whether the flow is a real- 
time flow or non-real-time flow. 

5 

An advantage of the present invention is that the real-time flow will be faster 
transferred over the network. 

Another advantage of the invention is that network recourses will be more 
10 efficiently used. 

Yet an advantage of the present invention is that real-time data is identified 
independendy of whether explicit description (e.g. by means of signalling) of the 
real-time flow is available or not. 



20 



Another advantage of the present invention is that, when it is used in radio access 
networks for detecting IP packet flows with real-time requirements, the resource 
allocation can then be optimised. This improves the network utilisation and the 
service quality perceived by the user. 



Further scope of applicability of the present invention will become apparent from 
the detailed description given hereinafter. However, it should be understood that 
the detailed description and specific examples, while indicating preferred 
embodiments of the invention, are given by way of illustration only, since various 
25 changes and modifications within the spirit and scope of the invention will 
become apparent to those skilled in the art from this detailed description. 



BRIEF DESCRIPTION OF THE DRAWINGS 

30 Figure 1 shows an RTP header. 

Figure 2 shows an overview of an IP network according to the invention. 
Figure 3 shows a flowchart of the general method of the invention. 
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DESCRIPTION OF PREFFERED EMBODIMENTS 

An RTP header will now be described according to RFC 1889 section 5, to 
5 simplify the understanding of the preferred embodiments. The RTP protocol unit 
header has some predictable properties that make it possible to test a UDP flow 
and tell if it contains RTP frames or not. However, the invention is not merely 
applicable to RTP flows only, it is applicable to other protocol formats that have 
similar predictable header behaviour. The format of the RTP header is shown in 
10 figure 1. The fields have the following meaning: 

Version V: 2 bits 



This field identifies the version of RTP. The version defined by this 
specification is two (2). 



15 



Padding P: 1 bit 



20 



If the padding bit is set, the packet contains one or more additional 
padding octets at the end which are not part of the payload. The last octet 
of the padding contains a count of how many padding octets should be 
ignored. Padding may be needed by some encryption algorithms with fixed 
block sizes or for carrying several RTP packets in a lower layer protocol 
data unit. 



Extension X: 1 bit 



25 



If the extension bit is set, the fixed header is followed by exactly one header 
extension, with a format defined in section 5.3.1 in the RFC mentioned 



above. 



30 



CSRC count CC: 4 bits 

The CSRC (synchronisation source) count contains the number of CSRC 
identifiers that follow the fixed header. 
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Marker M: 1 bit 

The interpretation of the marker is defined by a profile. It is intended to 
allow significant events such as frame boundaries to be marked in the 
packet stream. A profile may define additional marker bits or specify that 
5 there is no marker bit by changing the number of bits in the payload type 

field. This is further described in section 5.3 in the RFC mentioned above. 

Payload type PT: 7 bits 

This field identifies the format of the RTP payload and determines its 

10 interpretation by the application. A profile specifies default static mapping 

of payload type codes to payload formats. Additional payload type codes 
may be defined dynamically through non-RTP means, which is further 
described in section 3 in the RFC mentioned above. An initial set of default 
mappings for audio and video is specified in the companion profile 

15 Internet-Draft draft-ietf-avt-profile, and may be extended in future editions 

of the Assigned Numbers RFC. An RTP sender emits a single RTP payload 
type at any given time; this field is not intended for multiplexing separate 
media streams. 

20 Sequence number SN: 16 bits 

The sequence number increments by one for each data packet sent, and 
may be used by the receiver to be detect packet loss and to restore packet 
sequence. The initial value of the sequence number is random 
(unpredictable) to make known-plaintext attacks on encryption more 

25 difficult, even if the source itself does not encrypt, because the packets may 

flow through a translator that does. 

Timestamp TS: 32 bits 

The timestamp reflects the sampling instant of the first octet in the RTP 
30 data packet. The sampling instant must be derived from a clock that 

increments monotonically and linearly in time to allow synchronisation and 
jitter calculations (see further in section 6.3.1 in the RFC mentioned above) 
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The resolution of the clock must be sufficient for the desired 
synchronisation accuracy and for measuring packet arrival jitter (one tick 
per video is typically not sufficient). The clock frequency is dependent on 
the format of data carried as payload and is specified statically in the profile 

5 or payload format specification that defines the format, or may be specified 

dynamically for payload formats defined through non-RTP means. If RTP 
packets are generated periodically, the nominal sampling instant as 
determined from the sampling clock is to be used, not a reading of the 
system clock.- As an example, for fixed-rate audio the timestamp clock 

10 would likely increment by one for each sampling period. If an audio 

application reads blocks covering 160 sampling periods from the input 
device, the timestamp would be increased by 160 for each such block 
regardless of whether the block is transmitted in a packet or dropped as 
silence. 

15 

Synchronisation source SSRC: 32 bits 

The SSRC field identifies the synchronisation source. This identifier is 
chosen randomly, with the intent that no two synchronisation sources 
within the same RTP session will have the same SSRC identifier. An 

20 example algorithm for generating a random identifier is presented in 

Appendix A.6 in the above mentioned RFC. Although the probability of 
multiple sources choosing the same identifier is low, all RTP 
implementations must be prepared to detect and resolve collisions. If a 
source changes its source transport address, it must also choose a new 

25 SSRC identifier to avoid being interpreted as a looped source. 



Contributing source CSRC list: 0-15 items, 32 bits each 

The CSRC list identifies the contributing sources for the payload contained 
in this packet. The number of identifiers is given by the CC field. If there 
30 are more than 15 contributing sources, only 15 may be identified. CSRC 

identifiers are inserted by mixers, using the SSRC identifiers of contributing 
sources. For example, for audio packets the SSRC identifiers of all sources 
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that were mixed together to create a packet area listed, allowing correct [ 
talker indication at the receiver. i 



5 In figure 2 the preferred embodiment of the IP network 200 in which services are £ 
differentiated based on whether a transmitted flow 201, 202, 203 is a real-time 
flow or not. The IP network 200 comprises interconnected nodes 204 representing 

for example, switches, routers and hosts. An aggregated flow is defined as a mix of | 
all the different flows being transferred over a point in the IP network 200, each 4 
10 flow corresponding to an uni-directional packet stream of IP datagram from a I 
single session. Aggregated flows are transferred in the IP network 200 between the 

nodes 204. The IP network 200 also comprises Flow Classifiers 205 through f 
which an aggregated flow 201, 202 passes before entering a node 204. A Flow 
Classifier 205 can also be co-located in a node 204. 

15 

The Flow Classifier 205 has means 206 for distinguishing the incoming aggregated 
flow 201 into a set of flows, each flow corresponding to an uni-directional packet 
stream of IP datagram from a single session. This distinguishing makes it possible 
for the Flow Classifier 205 to look at a flow from a single session at a time. 

20 ?: 
The Flow Classifier 205 also has means 207 for checking payload size of the ? 
transport layer datagram of a packet in a flow of a particular session and also r 
means 213 for checking if the payload size of the transport layer datagram is larger 
than the smallest possible datagram of a specific session comprising real-time data. 

25 If it is, it might be a real-time flow, but if it is not, it is not a real-time flow. For 
example, checking if the UDP payload size is larger than the smallest possible RTP 
frame. 



The Flow Classifier 205 also has means 208 for looking at a number of 
30 consecutive data packets in the flow of the specific session and checking for static 
behaviour in the header fields, which are predictably constant if the flow of the 
particular session is a real-rime flow. For example, check if the header fields, that 
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are supposed to be constant in consecutive RTP frames within a session, are : \ 
constant in the investigated flow. Examples of constant RTP header fields are the 

version V field and the payload PT field. The payload type PT field tells what is { 

inside RTP, such as if it is GSM codec, if it is voice or if it is something else. These j 

5 are constant during the session if it is a real-time flow. If these header fields in the § 

investigated flow are not constant, it is a non-real-time flow. ! 

The Flow Classifier 205 also has means 209 for looking at a number of L 
consecutive data packets in the flow of the specific session and checking 

incremental behaviour of header fields, which are predictably incremented if the f 
flow of a particular session is a real-time flow. For example, checking in the 
possible RTP header if the fields that are supposed to be incremented, according, 
to above mentioned RFC 1 889, are incremented. Examples of incrementing RTP 
header fields are the sequence number SN field and the timestamp TS field. If 
these header fields, that are supposed to be incremented in the investigated flow, 
are not incremented, it is a non-real- time. flow. 

The Flow Classifier 205 further has means 212 for checking if the values of the 

header fields of an application datagram . satisfy the range restrictions of the header | 
20 of an application datagram comprising real-time data, e.g. an RTP frame. If the | 
range restrictions are not satisfied in the investigated flow, it is not a real-time | 
flow. t 

The Flow Classifier 205 further has means 210 for deciding whether the flow is a 
25 real-time flow or not, based on the previous checkings. When looking at a number 
of consecutive data packets in the flow, consideration has to be taken that some 
packet or packets might be missing. 

The Flow Classifier 205 has means 211 for reporting the decision whether the 
flow is a real-time flow or not to the node 204. 

30 
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In one embodiment of the present invention, an outgoing link 203 of the node 

204 constitutes a radio link and the node 204 has means 214 for allocating radio fj 
resources on basis of the flow being a real-time flow or not. \ 

5 In another embodiment, the node 204 has means 215 to request the link layer to h 
either recover from errors if the flow is a non-real-time flow or not recover from 
errors if the flow is a real-time flow. There is no requirement for recovering from 
errors when transferring real-time data. : 

10 In yet another embodiment, the node 204 constitutes a switch. The switch has 
means 216 for prioritising a real-time flow over non-real-time flow when 
switching, e.g. in situations of temporary overload. j 

In yet another embodiment, the node 204 constitutes a router. The router has 
15 means 216 for prioritising a real-time flow over non-real-time flow when routing, 

e.g. in situations of temporary overload. 1 



Figure 3 shows a flowchart of a possible scenario of distinguishing a real-time flow 
20 from other types of flows in a stream of IP packets in an IP network 200. The IP 
network 200 comprises interconnected nodes 204. Aggregated flows are 
transferred in the IP network 200 between the nodes 204. The node 204 has 
accordingly an incoming aggregated flow of IP datagram. The incoming aggregated 
flow is distinguished 300 into a set of flows, where each flow corresponds to an 
25 uni-directional packet stream from a single session. This makes it possible to look 
at a flow from a single session at a time. 

The method then comprises at least one of following checkings: 
- Checking payload size 301 of the transport layer datagram of a packet in a flow 
30 of a particular session. In one embodiment it is also possible to check if the 

payload size of the transport layer datagram is larger than the smallest possible 
datagram of a specific session comprising real-time data, e.g. checking if the 
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UDP payload size is larger than the smallest possible RTP frame. If it is, it 
might be a real-time flow. If it is not, it is not a real-time flow. 

- Checking if the values of the header fields of an application datagram satisfy the 
range restrictions 302 of the header of an application datagram comprising 

5 real-time data, e.g. an RTP frame. If the range restrictions are not satisfied in 

the investigated flow, it is not a real-time flow. 

- Looking at a number of consecutive data packets in the flow of the specific 
session and checking for static behaviour 303 in the header fields that are 
predictably constant if the flow of the particular session is a real-time flow. For 

10 example checking if the header fields that are supposed to be constant in 

consecutive RTP frames within a session are constant in the investigated flow. 
Examples of constant RTP header fields are the version V field and the 
payload PT field. The payload type PT field tells what is inside RTP such as if 
it is from a GSM codec, if it is voice or if it is something else. These are 

15 constant during the session if it is real-time. If these header fields in the 

investigated flow are not constant, it is not a real-time flow. 

- Looking at a number of consecutive data packets in the flow of the specific 
session and checking incremental behaviour 304 of header fields, which are 
predictably incremented if the flow of a particular session is a real-time flow. 

20 For example checking in the possible RTP header if the fields that are 

supposed to be incremented, according to above mentioned RFC 1889, are 
incremented. Examples of incrementing RTP header fields are the sequence 
number SN field and the times tamp TS field. If these header fields that are 
supposed to be incremented in the investigated flow are not incremented, it is 

25 not a real-time flow. 

The method comprises the further step of deciding 305 whether the flow is a real- 
time flow or not, based on the previous checkings. 

30 



The performed checkings are each resulting in either non-real-time flow or 
possible reai-time flow. If one of the checking steps above shows that it is non- 
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real-time data, then no more checkings are required. An example of how these 
checkings can be performed will now be described: 

First, checking if the payload size of the UDP payload size is larger than the 
5 smallest possible RTP frame. If it is not, the flow is classified as a non-real-time 
flow. If it is, it might be a real-time flow and further checkings are required. 

If so, follows a checking if the values of the header fields of an application 
datagram satisfy the range restrictions 302 of an RTP header. If the range 

10 restrictions are not satisfied in the investigated flow, the flow is classified as a non- 
real-time flow. If they are satisfied it might be a real-time flow and further 
checkings are required. In that case next step is to check if the header fields that 
are supposed to be constant in consecutive RTP frames within a session are 
constant in the investigated flow. If they are not constant, the flow is classified as a 

15 non-real-time flow. If they are constant, it is a possible real-time flow and further 
checking is required. 

In that case, checking in the possible RTP header if the fields, that are supposed to 
be incremented in consecutive RTP frames according to above mentioned RFC 
20 1889, are incremented. If these header fields are not incremented, the flow is 
classified as a non-real-time flow. On the other hand, if these header fields are 
incremented, the flow is classified as a real-time flow. 

When looking at a number of consecutive data packets in the flow and checking 
25 for incremental behaviour, consideration has to be taken into that some packet or 
packets might be missing. 

In one embodiment the method comprises a step of reporting the decision 
whether the flow is a real-time flow or not, to the node 204. 

30 
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CLAIMS 

1. An IP network (200) having service differentiation based on whether a $ 
transmitted flow (201, 202, 203) is a real-time flow or not, the IP network | 

5 (200) comprising a node (204) receiving an incoming aggregated flow (201) of f 

f 

IP datagram via a Flow Classifier (205), characterised by the Flow Classifier I 
(205) having; f. 

- means (206) for distinguishing the aggregated flow into at least one set of 5 
flows, each flow corresponding to a uni-directional packet stream from a f 

10 particular session, L 

and the Flow Classifier (205) having at least one of the following means; 

- means (207) for checking the payload size of the transport layer datagram 
of a packet in a flow of a particular session; 

- means (208) for checking for static behaviour in header fields, of a number 
15 of consecutive data packets in the flow of the particular session; or 

- means (209) for checking for incremental behaviour of header fields, of a 
number of consecutive data packets in the flow of the particular session; 
and 

the Flow Classifier (205) further having: 
20 - means for performing one of said checkings; f 

- means for performing a further one of the not yet performed said P 
checkings, if said performed first checking results in that the flow possible 

is a real-time flow; 

- means for performing a yet further one of the not yet performed said 
25 checkings and so on until all said checkings are performed, 

- means for deciding that the flow is a real-time flow, if the last performed 
checking step results in that the flow possible is a real time flow. 

2. The IP network according to claim 1, characterised in Flow Classifier (205) 
30 comprising means (211) for reporting to the node (204) whether the flow is 

real-time flow or not. 
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3. The IP network (200) according to any of the claims 1 and 2, characterised by 
the Flow Classifier (205) having means (212) for checking if the values of the 
header fields of an application datagram in a flow of a particular session satisfy 

5 range restrictions for a header of an application datagram comprising real-time 

data. 

4. The IP network (200) according to any of the claims 1-3, characterised by the 
Flow Classifier (205) having means (213) for checking if the payload si2e of the 

10 transport layer datagram is at least as large as the smallest possible datagram of 

any session comprising real-time data. 

5. The IP network (200) according to any of the claims 1-4, wherein an outgoing 
link (203) of the node (204) is a radio link, characterised by the node (204) 

15 having means (214) for allocating at least one radio resource on basis of the 

flow being a real-time flow or not. 



6. The IP network (200) according to any of the claims 1-5, characterised by the 
node (204) having means (215) for requesting the link layer to recover from 

20 errors if the flow is non-real-time flow. 

7. The IP network (200) according to any of the claims 1-5, characterised by the 
node (204) having means for requesting (215) the link layer not to recover 
from errors if the flow is a real-time flow. 

25 

8. The IP network (200) according to any of the claims 1-4, wherein the node 
(204) is a switch, characterised by the switch having means (216) for 
prioritising a real-time flow over non-real-time flows when switching. 

30 9. The IP network (200) according to any of the claims 1-4, wherein the node 
(204) is a router, characterised by the router having means (216) for 
prioritising a real-time flow over non-real-time flows when routing. 
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10. The IP network (200) according to any of the claims 1-9, characterised by the 
real-time flow carrying RTP (Real-time Transfer Protocol) frames and the 
flows is a UDP (User Datagram Protocol) flow. 

5 

11. A Flow Classifier (205) for classifying whether a transmitted flow, comprising 
datagrams, within an IP network (200) is real-time flow or not, the Flow 
Classifier (205) receiving an incoming aggregated flow (201) of IP packets 
characterised by the Flow Classifier (205) having; 

10 - means(206) for distinguishing at least one set of flow in the aggregated 

flow, each flow corresponding to a uni-directional packet stream from a 
single session, 

the Flow Classifier (205) having at least one of the following means; 

- means (207) for checking the payload size of the transport layer datagram 
15 of a packet in a flow of a particular session; 

- means (208) for checking for static behaviour in header fields of a number 
of consecutive data packets in the flow of a particular session; 

- means (209) for checking for an incremental behaviour of header fields, of 
a number of consecutive data packets in the flow of a particular session; 

20 the Flow Classifier (205) further having: 

- means for performing one of said checkings; 

- means for performing a further one of the not yet performed said 
checkings, if said performed first checking results in that the flow possible 
is a real-time flow; 

25 - means for performing a yet further one of the not yet performed said 

checkings and so on until all said checkings are performed, 

- means for deciding that the flow is a real-time flow, if the last performed 
checking step results in that the flow possible is a real time flow. 

30 12 The Flow Classifier (205) according to claim 11, characterised by the Flow 
Classifier (205) having means (212) for checking if the values of the possible 
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header fields of an application datagram in a flow of a particular session satisfy 
range restrictions of a header of an application datagram comprising real-time 
data. 

5 13 The Flow Classifier (205) according to any of the claims 11-12, characterised 
by the Flow Classifier (205) having means (213) for checking if the payload size 
of the transport layer datagram in a flow of a particular session is at least as 
large as the smallest possible datagram of any application comprising real-time 
data. 

10 

14 The Flow Classifier (205) according to any of the claims 11-13, characterised 
bv the real-time flow carrying RTP (Real-time Transfer Protocol) frames and 
the flow is a UDP (User Datagram Protocol) flow. 

15 15. Method for distinguishing a real-time flow from non-real-time flows in a 
stream of IP packets in an IP network (200), the IP network (200) comprising 
a node (204) receiving an incoming aggregated flow of IP datagram, 
comprising the step of: 

r 

- distinguishing (300) at least one set of flow in the incoming aggregated flow 
20 where each distinguished flow corresponds to a uni-directional packet 

stream from a single session; 
and performing one of the following checking steps: 

- checking (301) the payload size of the transport layer datagram of a packet in 
a flow of a particular session; 

25 - checking (302) if the values of the possible header fields of an application 

datagram in a flow of a particular session satisfy the range restrictions of a 
header of an application datagram comprising real-time data; 

- checking (303) for static behaviour in header fields, of a number of 
consecutive data packets of a particular session; 

30 — checking (304) for incremental behaviour of header fields, of a number of 

consecutive data packets of a particular session; 
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if said checking results in that the flow possible is a real-time flow, 

- performing a further one of the not yet performed said checking steps; 
if said farther checking results in that the flow possible is a real-time flow, 

- performing a farther one of the riot yet performed said checking steps, 
5 and so on until all checking steps are performed; 

if the last performed checking step results in that the flow possible is a real-time 
flow, 

- deciding (305) that the flow is a real-time flow. 

10 16. The method of claim 15, comprising the further step of reporting the decision 
(305) to the node (204). 

17. The method according to any of the claims 15 and 16, wherein the step of 
checking the payload size (301) of the datagram of the transport layer 
15 comprises checking if payload the size of the datagram of the transport layer is at 

least as large as the smallest possible datagram of any session comprising real- 
time data. 



18. The method according to any of the claims 16-17, wherein an out-going link 
20 (203) of the node (204) is a radio link, comprising the further step to be taken 

after reporting the decision to the node (204): 

allocating at least one radio resource on basis of whether the flow is a real-time 
flow or not. 

25 19. The method according to any of the. claims 16-18, comprising the further step 
to be taken after reporting the decision to the node (204): 

requesting the link layer to recover from errors if the flow is non-real-time flow. 

20. The method according to any of the claims 16-18, comprising the further step 
30 to be taken after reporting the decision to the node (204): 

requesting the link layer to not recover from errors if the flow is a real-time flow. 
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21. The method according to any of the claims 16-17, comprising the further step 
to be taken after reporting the decision to the node (204), the node (204) being 
a switch: 

prioritising a real-time flow over non-real-time flows when switching. 

5 

22. The method according to any of the claims 16-17, comprising the further step 
to be taken after reporting the decision to the node (204), the node (204) being 
a router : 

prioritising a real-time flow over non-real-time flows when routing. 

10 

23. The method according to any of the claims 15-22, wherein the real-time flow 
carries RTP (Real-time Transfer Protocol) frames and the flow is a UDP (User 
Datagram Protocol) flow. 
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